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Method and System for Automatic Detection of Monitoring Data Sources 

This application claims the benefit of U.S. Provisional Application No. 
5 60/43 1 ,076, filed December 5, 2002. 

Field of the Invention 

This invention relates generally to computer systems, and more specifically to 
tools for assisting in the management and monitoring of computer systems and network 
10 infrastructure. 

Background of the Invention 

Complex computer systems, such as e-commerce systems, may include web- 
servers, file servers, databases, billing servers, etc. Other examples of complex computer 
15 systems are Enterprise Resource Planning (ERP) systems, Enterprise Application 
Integration (EAI) systems, other enterprise applications, distributed applications, 
infrastructure and telecommunication applications, and many more. Because of their 
complexity, such computer systems need continued attention from qualified persons to 
ensure error-free and efficient operation. 

20 

The complexity of the system makes errors and possible inefficiencies more likely 
to occur and harder to find, once they have occurred. As a result, maintenance of these 
systems can be challenging and time consuming. One aspect of the maintenance of such 
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complex systems is monitoring the performance of all the applications that make up the 
system. 

Computer systems often provide the ability for a person to check various 
information associated with such systems. This information may include status, 
throughput, performance, configuration, business, accuracy, availability, security, 
utilization, geographical, and usability information. This type of information is referred to 
as monitoring information. Some examples on how monitoring information can be 
accessed remotely are: 

• applications, devices, or operating systems may provide their monitoring 
information by making use of certain operating system services specifically 
designed for this purpose. For example, the SNMP agent service or Microsoft's 
remote registry are designed for being accessed remotely; 

• custom tools provided by an operating system or an application, such as command 
line tools; 

• custom services/daemons implemented by some applications or devices that can 
be accessed locally as well as remotely, such as dynamically generated WebPages 
which contain HTML formatted monitoring information; 

• an application or device may be shipped with tools that query this application or 
device once it is deployed, and return monitoring information, usually in a non- 
standardized format; 

• a network router or switch may provide monitoring information, such as network 
traffic statistics, via SNMP; 
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• « 

• a computer may be configured to continuously produce files containing 
monitoring information pertaining to the system; 

• a database may provide monitoring information through standard database-client 
interfaces such as OCI (Oracle Calling Interface) or ODBC (Open DataBase 

5 Connectivity); 

In a more specific example, a user may be interested in measuring the utilization 
of a system's CPU(s). On Microsoft Windows platforms, the user would have to launch a 
Microsoft specific GUI tool, pick out of a large number of monitoring information 

10 options the one which allows the user to query a Microsoft specific service for accessing 
this kind of utilization information. On other systems it would suffice to execute a 
command line tool, which produces a tabular text output containing each CPU's 
utilization. Such tools can be utilized from remote locations and the tabular text output 
can be transferred back to the caller. For example, Sun operating systems feature the 

15 command line tool "mpstat", which provides CPU utilization information. The "mpstat" 
tool can be remotely executed by using the REXEC protocol, a commonly used remote 
execution protocol in Sun operating systems and other UNDC operating systems. Thus, in 
order to remotely retrieve the CPU utilization information from a SunOS powered host a 
user would need to: 

20 • connect to the host on port 5 1 2 using the REXEC protocol (port 5 1 2 is the default 
connection point of the REXEC protocol); 

• remotely execute a tool named "mpstat" via REXEC; 

• produce tabular text output; 
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• find the needed utilization information in the tabular output. 

A monitoring information service (service) is a service, daemon, tool or any other 
interface that is able to provide monitoring information concerning a particular computer 
5 system. However, these services are not standardized and may be very different for 
different computer systems. Often a computer system provides monitoring information in 
such a manner that a user must be very well versed in the configuration of the hardware 
devices as well as the software applications running on the devices, in order to access this 
information. Although some tools for collecting and analyzing monitoring information 
10 are available, usually these tools must be manually configured to indicate the location of 
the needed information and/or how to extract it. They are thus inefficient and difficult to 
use. 

Summary of the Invention 

15 The present invention is directed to a method and system of using an expert's 

knowledge of the manner in which different computer systems provide performance 
information in order to allow a user to quickly and conveniently access this performance 
information. 

20 The present invention is directed to a method and system for interfacing with 

various monitoring information sources from one or more computer systems with 
minimal user input. A computer system may include one or more computers as well as 
any number of devices such as networking devices. Another aspect of the invention is the 
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embedding of expert knowledge in data source monitoring software. These sources can 
later be used by data collection tools in order to extract monitoring information, and 
present the information to the user or use it in another way (such as storing it or raising an 
alert when a certain monitored value exceeds a threshold). Furthermore, the user may 
5 decide which sources of information should be monitored by the data collection tools. 
The user may also use the present invention in order to inform him/herself of the 
configuration of the system he/she is monitoring. 

Another aspect of the present invention relates to collecting certain configuration 
10 information (meta information) of the computer system and network environment. Such 
information may include information regarding the setup of the system being examined, 
such as the number of processors or the operating system version, or even the various 
computers or devices that make up the system. The meta information may be used to 
identify possible performance information sources. The meta information may also be 
15 presented to the user, together with the available performance data sources, in order to 
inform the user of the configuration of the system being monitored. 

Utilizing the present invention in conjunction with tools for collecting monitoring 
information, the user may view various pieces of monitoring information from various 
20 computer systems, without having to specify the sources of this information. The user 
need not know the particular way each application stores or provides performance 
information. User involvement in the gathering of the information is required only when 



{M:\6896\l m098us 1\000650 1 5 .DOC lIlilillllllllliHUilllllll } 



Page: 5 



absolutely needed — for example when an unknown password is needed to obtain the 
performance data of a certain application. 



5 Brief Description of the Drawings. 

The foregoing and other features of the present invention will be more readily 
apparent from the following detailed description and drawings of the illustrative 
embodiments of the invention wherein like reference numbers refer to similar elements 
and in which: 

10 

Figure 1 is a block diagram of an exemplary embodiment of the present invention; 

Figure 2 is a flow chart of interaction between the data source detection module, the data 
collection tools and the user; 

15 

Figure 3 is a block diagram of the data source detection module; 
Figure 4 is a diagram showing data structures within the configuration; 
20 Figure 5 is a flow chart of the data source detection process; 
Figure 6 is a flow chart of the service probe; 
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Figure 7 is a flow chart of the probing process for MISs; 
Figure 8 is a flow chart of a method for probing metrics; 
5 Figure 9 is a flow chart of a validation process; 

Figure 10 is a diagram of a detected metric within a list of detected metrics; 
Figure 11 is a diagram of a single MIS within a list of MISs; and 

10 

Figure 12 is a diagram of an exemplary configuration and the list of detected metrics. 

Detailed Description of the Exemplary Embodiments. 

Figure 1 is a block diagram showing the major components of an exemplary 
15 embodiment of the present invention. A data source detection module 100 utilizes a 
configuration 102 in order to acquire instructions on how to probe environment 104 for 
meta and performance information. The graphical user interface (GUI 106) enables the 
user to interact with the data source detection module 100, and optionally with the data 
collection tools 108 as well. Alternatively, the data collection tools 108 may use a 
20 different GUI to interact with the user. Once the data source detection module 100 
identifies performance information sources, it may inform one or more data collection 
tools 108 of all or some of these performance information sources. 
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A configuration 102 is used to describe which applications or computers are to be 
queried and how they are to be queried. Figure 4 is a schematic representation of an 
exemplary configuration. Other configuration formats, such as for example using XML, 
are also possible. 

5 

The configuration 102 includes the necessary information to query servers and/or 
applications that may be used by a client. Different configurations may be used for 
different clients, and may be updated as new servers and/or software applications appear 
or become popular. It should be noted that while customizing the configuration 102 for 
10 particular clients may be beneficial, one does not need to know the exact set of 
applications a client is running in order to create a configuration. In other words, the 
client's hardware and software will typically be a subset of all the hardware and software 
described in the configuration 102. 

15 Figure 2 shows the interaction between the data source detection module, the user 

and the data collection tools. In step 200, the data source detection module 100 identifies 
the data sources in the Internet applications and environment 104 and presents them to 
the user via the GUI 106. In step 202, the user examines the data sources and selects the 
ones he/she wants to monitor, using the GUI 106. In step 204, the data collection tools 

20 receive the list of sources selected by the user. These sources can be received from the 
GUI or from the data source detection module. Alternatively, some information about 
these sources may be received from the GUI and some from the data source detection 
module. In step 206, the data collection tools extract performance data from the Internet 
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applications and environment. Such extraction can be performed at one time or 
continuously depending on the particular data source and/or instructions entered by the 
user. At step 208, the data collection tools present the extracted information to the user 
via the GUI. Such presentation may be performed in a manner that is informative and 
5 helpful to the user, such as using graphs or charts. 

As shown in Figure 3 the data source detection module 100 includes a pool of 
probe engines 300, a list of Monitoring Information Source (MIS) 302 and a list of 
detected and validated monitoring data sources (or detected metrics) 304. A Monitoring 

10 Information Source is an element of a computer system for which there potentially exists 
relevant monitoring information. For example, given a computer with four processors, 
each processor is an MIS. Relevant monitoring information for each processor may 
include CPU Utilization, Kernel Time or User Time. An MIS need not actually provide 
the monitoring information to the data source detection module 100 itself, but is the 

15 element with which that information is associated. For example, while a processor may 
be an MIS, it is probably not a service, because a processor is unlikely to provide 
monitoring information directly to the data source detection module. It is possible for the 
same element to be an MIS and a service but it is not required. For example, a web-server 
that can be queried directly for its monitoring information is both a service and an MIS. 

20 

A metric is a piece of monitoring information that is directly related to a certain 
MIS. Several metrics may be associated with a single MIS, but a metric can only be 
associated with one MIS. The list of detected metrics 304 is used to accumulate metrics 
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as they are detected by the data source detection module 100. This list eventually 
becomes part of the results that the data source detection module provides the client or 
the data collection tools. 

5 A probe engine is a software module used for probing services for monitoring 

information sources. All probe engines must provide the same well-defined interface in 
order for the data detection module to be able to use them in a similar way. In normal 
operation the data source detection module 100 may contain multiple instances of several 
types of probe engines which make up the probe engine pool 300. A separate instance of 

10 a probe engine is used in conjunction with each separate service. Different types of probe 
engines are provided for different types of services. For example, a certain type of probe 
engine may be used for a command line based service, while another type of probe 
engine may be used for a GUI based service. Each probe engine implements the specific 
logic needed to communicate with a particular type of service. Probe engines may be 

15 added or removed from the data source detection module 100 in order to update it. New 
probe engines may be added in order to support new services. 

Configuration 102 includes a Service Table, an MIS Detection Table and a 
Metric Table. Figure 4 shows a Service Table row 400, a Detection Table row 410, and a 
20 Metric Table row 420. Only a single row from each table is shown. Each row of the 
Service Table 400 describes a service that can be possibly used to provide monitoring 
information for the environment. Similarly, each row of the MIS Detection Table 410 
describes the information needed to discover an MIS in the environment and each row of 
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the Metric Table 420 describes a metric that can possibly be obtained for a particular 
MIS. 

Service table row 400 contains several fields, such as the Name field 401 which 
5 specify the service name. The service name is used by the data source detection module 
to determine which probe engine type to use for that particular service. The Connectlnfo 
field 402 contains information needed to connect to the particular service. Such 
information may be a port number, for example. The information in the Connectlnfo field 
is in a form tailored for the particular probe engine that will be used for the service. For 

10 example, the Connectlnfo field may contain the number 512, and the probe engine 
handling the object may be configured to treat that number as a port number. Fields 403, 
404, 405, 412, 413, 414, 422, 423, 424, 425 are similarly tailored to the type of probe 
engine that will process them. The RequestParams field 403 is used to describe the 
request that the probe engine should use to access the service. The request specified in 

15 field 403 is used by the probe engine to validate the service and to gather meta 
information from the service. The RequestParams field may include a command line such 
as "mpstat". It may also include parameters that are meant to be used with a command 
line. The ResponseParselnfo field 404 is used to specify how the response from the 
service is to be parsed. An example of the contents of field 404 is "get column 2" or just 

20 "2", which may be interpreted by the probe engine to mean "get column 2". The 
Validationlnfo field 405 is used to specify a test which must ensure that the service is 
valid, i.e., present and functioning. An example of field 405 contents is "OS Version", 
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which may be interpreted by the probe engine to mean "service is valid if the parsed 
information contains string 'OS Version 1 ." 

MIS Detection Table row 410 contains several fields as well. The Name field 41 1 
5 provides the name of the MIS. The ServiceName field 412 contains the name of the 
service with which the MIS is associated. An MIS is associated with the service that 
provides data about that MIS. The RequestParams field 413 is similar to the 
RequestParams field 403. The difference is that field 413 contains request information 
that is needed to obtain data pertaining to the MIS. The ResponseParselnfo field 414 is 
10 similar to the response parse info field 404. However it is used to parse for information 
about MIS and not for meta data or service validation information. 

The Name field 421 of the Metric Table row 420 is used to specify the name of a 
metric. The MISName field 422 is the name of the MIS with which the metric is 

15 associated. The RequestParams field 423 is similar to field 403 and 413 but it specifies 
request parameters for retrieval of the metric. The ResponseParselnfo field 424 is similar 
to fields 404 and 414 but it describes how information relating to the metric should be 
parsed. The Validationlnfo field 425 describes a test that should be used to ensure that the 
metric is valid. This test differs from the test described in field 405, because a service 

20 may be valid, but it may be unable to provide valid information regarding a certain 
metric. For example if a service for some reason is unable to provide a processor 
utilization rate, it may display an "X" in the space where this information is meant to be 
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provided to indicate that no information is available. In such a case field 425 will 
describe a test whether or not an "X" is present. 

Before data source detection is initiated, the list of detected monitoring 
5 information sources 302 and the list of detected metrics 304 are empty. The pool of probe 
engines contains a single probe engine of each possible type. The user initially specifies 
the scope of the environment 104 to be examined. The user can do this by entering a list 
or a range of network addresses of the computers or devices (machines) that are to be 
examined. 

10 

The data source detection module loads the configuration 102, and performs the 
process described in Figure 5 for each machine in the environment. In step 501 the data 
source detection module picks up the first row in the service table in the configuration 
102, or if that row has already been processed, the next unprocessed row in the service 

15 table. The data source detection module probes the environment 104 in step 502 to 
determine if the service described by the current row in the service table is available. 
When it processes a row in the service table the data source detection module 100 
activates a probe engine from the pool of probe engines. The type of the activated probe 
engine depends on the type of service described in the particular row. The type of service 

20 is determined by the Name field 401 in the service table. 

The probe engine loads the information from the service table and starts the 
process of probing for a service, described in the service table. The probe engine uses the 
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information in the Connectlnfo 402 field to determine where it should look for the 
service. If a service is available the probe engine moves on to step 503 where it identifies 
the MIS(s) for which the service is providing information. These MISs are stored in the 
list of detected MISs 302. Once the MISs are stored and identified the probe engine in 
5 step 504 finds and validates all the metrics that are associated with any of the MISs. Steps 
502, 503 and 504 are shown in more detail in Figures 6, 7 and 8, respectively. 

Probing for services means that the probe engine verifies whether the service is 
responding (step 602 in Figure 6). If authentication is required for accessing the service, 

10 the data source detection module 100 will ask the user via GUI 106 for authentication 
data, such as username and password. If the service is responding, the service is used to 
determine meta information of the environment the service is running in. This meta 
information is requested in step 603 by the probe engine using the request parameters 
403. Request parameters 403 may include a command which the probe engine is to 

15 provide to the service. Meta information may include, for example, the version of the 
operating system or the version of the service. The probe engine parses the response 
using the response parse information 404 and validates it using validation information 
405. If, on the other hand, at step 602, the service is not responding, the probe engine is 
returned into the pool of probe engines (step 604), the service is identified as not 

20 available, and a new row in the service table is processed. 

The process of validation is similar for services or metrics and is shown in Figure 
9. At first in step 901 a request is sent to a service according to the request parameters. 
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These request parameters can be the service request parameters 403 or the metric request 
parameters 423 depending on whether a service or metric is being validated. 
Subsequently, in step 902 the response is parsed using response parse information 404 or 
424. Finally, at step 903, validity is determined according to the parsed response and a 
5 condition contained in the validation information 405 or 425. The result of a validation 
process is either valid or invalid. An invalid result means that the particular service or 
metric being validated does not exist. A valid result means it does exist. 

Each service which is successfully probed (probing process 502) is used by the 
10 data source detection module 100 for the subsequent MIS probing process 503 and the 
metric probing process 504. 

The MIS Probing process 503 is illustrated in more detail in Figure 7. In step 701 
the probe engine picks up the next (or the first) row in table 410 of the configuration. In 

15 step 702, the probe engine sends a request to the corresponding service using the request 
parameters 413. In step 703, the response is processed by the probe engine. In the 
processing step the probe engine identifies all available MIS instances using the response 
parse information 414. If any MIS instances are extracted in step 704 they are stored in 
the list of detected MISs 302. A probe engine may find several instances of MISs, all 

20 corresponding to a single row in table 410 in the configuration 102. For example, the 
MIS detection table may contain one row corresponding to a processor but the service 
may report that a certain computer has several processors. If this is the case several 
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entries, one for each found MIS, are stored in the list of detected MISs 302, and each 
stored instance is accompanied with an unique ED. 

The list of detected MIS 302 is preferably implemented as a detected MIS table. 
5 Each row in the table represents one detected MIS instance. An example of such a row is 
shown in Figure 10. The ServiceName field 1001 in the row specifies the service with 
which the MIS instance was detected. The same service will be used later in order to 
probe the MIS for the metrics specified in the metric table. The ServiceName field 1001 
corresponds to ServiceName field 412 of the MIS detection table row 410. The 

10 MISName field 1002 similarly corresponds to the Name field 411. The MISJD field 
1003 is a unique identification of the MIS instance. As mentioned above more than one 
MIS instances can be found that correspond to the same MIS type specified by a row in 
MIS detection table 410. This is because a single service may list information for 
multiple MIS instances of the same type, e.g., multiple processors. The instance 

15 identifications of a particular MIS type is the result of the MIS probing process. The 
instance IDs are stored together with the associated service name and MIS name in the 
MISJD field 1003, ServiceName 1001 field and MISName field 1002 in the detected 
MIS table 1000. 

20 Once the probe engine is finished with the MIS Probing process 503, it has to 

examine what kind of monitoring information is available for the found MIS stored in the 
list of detected MISs 302. The probe engine queries and validates various pieces of 
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monitoring information (metrics) for each row in the list of detected MISs 302 by 
referring to the metric table, in the configuration 102. 

The metric probing process is shown in Figure 8. In step 801 the probe engine 
5 moves on to the next (or the first) MIS in the list of detected MIS. In step 802 the probe 
engine moves on to the next (or first) metric associated with the current MIS. The probe 
engine determines which metrics are associated with the current MIS by examining the 
MISName 422 field of the metric. In step 803 the probe engine probes for the validity of 
the metric by making a request to the service, using the RequestParams field 423 of the 
10 metric, parsing the response in accordance with the ResponseParselnfo 424 of the metric 
and checking whether the metric is valid by using the test described in the Validationlnfo 
field 425 of the metric. If the metric is valid it is stored in the list of detected metrics 304 
(step 804). Steps 806 and 808 cycle to the next metric for the current MIS, or the next 
MIS if all the metrics for the current MIS have been processed. 

15 

Each detected metric in the list of detected metrics 304 is represented as a row in 
a DetectedMetric table. An example of such a row is shown as 1100 in Figure 11. The 
Name field 1 101 in the DetectedMetric table 1 100 differs from the Name field 421 in the 
metric table row 420 in the configuration 102. It is a combination of the name of the MIS 
20 to which the metric refers to (422) and the metric Name (421). The ServiceName 1 102 is 
the service which was queried to validate the metric. It is taken from the service name 
1001, corresponding to the MIS instance in the list of detected MISs 302 with which the 
metric is associated. The Connectlnfo field 1103 is taken from the Connectlnfo field 402 
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of the service which provided the metric. The Authenticationlnfo field 1104 is set to 
contain the authentication information, if any, that was requested from the user in order to 
access the service that provided the metric. The MIS_ID 1 105 is taken from the MIS_ID 
1003 of the same MIS. The RequestParams 1106 field is set to the value of 
5 RequestParams field 423, the ResponseParselnfo field 1 107 is set to the current value of 
ResponseParselnfo field 424. 

Figure 12 illustrates an exemplary configuration and list of detected metrics. In 
this example a machine running SunOS is queried, its CPUs are the MIS and the REXEC 

10 daemon is the service. Several of the data structures are shown with appropriate values. 
Service table 1240 corresponds to service table row 400, thus fields 1201, 1202, 1203, 
1204, 1205 correspond to fields 401, 402, 403, 404 and 405, respectively. MIS detection 
table 1250 corresponds to table row 410, and fields 1210, 1211, 1212 and 1213 
correspond to fields 411, 412, 413 and 414, respectively. Metric table 1260 corresponds 

15 to table row 420 and fields 1220, 1221, 1222, 1223 and 1224 correspond to fields 421, 
422, 423, 424 and 425, respectively. The list of detected metrics corresponds to the list 
304, where each detected metric table in the list is represented as a row. Fields 1230-1236 
correspond to fields 1 101-1 107, respectively. 

20 With reference to the MIS probing process shown in Figure 7 and the example of 

Figure 12, the probing engine reaches MIS detection table 1250 in the configuration 
(step701). In step 702 the request parameter 1212 requires the execution of the command 
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line tool "mpstat" via the REXEC daemon. The probe engine uses the request parameter 
1212 and causes the REXEC daemon to execute "mpstat". An exemplary result is: 

0 15 0 25 105 105 50 0 0 4 0 98 0 1 2 97 

1 16 0 30 100 100 49 0 0 4 OX X X 2 98 
5 2 15 0 27 112 112 49 0 0 4 0 97 0 1 1 98 

3 16 0 341 439 238 46 X X X X 90 0 0 4 96 

This exemplary result identifies four processors, each processor being described 
by a row. The first column is a processor identification number, and the following 

10 columns are the values of various metrics, wherein an "X" signifies that the 
corresponding metric is not available. The probe engine reads the response and extracts 
the MIS identifications according to the response parse parameter 1213 (step 703). The 
response parse parameter 1213 signifies that the MIS identification is saved in the very 
first column (column 0). The response consists of four rows, and therefore the probe 

15 engine will place in the list of detected MISs 302 four instances of MISs with the 
MISName fields 1001 set to "Processor" and MISJD fields 1003 set 0, 1, 2 and 3, 
respectively (step 704). These four instances represent the four processors. Of course, 
other scenarios are possible when other probe engines, operating systems and/or services 
or daemons are present. 

20 

With reference to the metric probing process shown in Figure 8 and the example 
of Figure 12, step 801 finds the first MIS instance present in the list 302, i.e., the first 
processor. In step 802 the only metric (Kernel Time) is picked up because it is associated 
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with the first processor. In step 803 the data source detection module attempts to verify 
that for processor(O) the kernel time can be queried and will provide valid information. 
Based on the RequestParams field 1222, the probe engine will cause the REXEC daemon 
to execute a command line tool called "mpstat". In this example, the command returns 
5 the following string for processor(O): 

0 15 0 25 105 105 50 0 0 4 0 98 0 1 2 97 

In this resulting string the Kernel Time is represented by the second column 
(identified as column 1, since the first column is column 0). The probe engine will pick 
10 up column 1 based on ResponseParselnfo field 1223. The probe engine will successfully 
verify the value of column 1, based on the Validationlnfo field 1224, because it is a 
number. In step 804 the verified metric for the first processor (Proc 0) is stored as a row 
in the list of detected metrics 1270. Similarly the same metric for the other three 
processors is stored. 

15 

Once all services listed in the configuration are queried, the validated monitoring 
information sources and the validated metrics containing information about the MISs are 
obtained. This process is repeated for each machine in the user specified environment to 
retrieve similar MISs and metric groups for each such machine. Thus, the invention 
20 produces a description of what monitoring information is available and how this 
information can be accessed. The resulting information may be presented to the user via 
the GUI 106 or sent to data collection tools 108, as described in Figure 1 . 
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A graphic user interface 106 is used to communicate with the user. The GUI 106 
allows the user to initiate data collection, view the results, and enter passwords if needed. 
The GUI may also interface with one or more data collection tools 108, that are used in 
conjunction with the data source detection module. The data source detection module 
5 may either store the results to a file or it may be queried for its results. 

The data collection tools 108 are tools that use the data sources or performance 
information sources, identified by the data source detection module, in order to collect 
performance information from them. 

10 

The data source detection module 100 may be running from within the 
environment 104 it is examining, i.e., on an Internet server. It may also run on a remote 
computer and query the environment 104 through the Internet or another computer 
network. Similarly, the GUI 106 may run on the same computer as the data collection 
15 module 100, or it may run on a different computer or on a terminal and communicate 
with the data collection module 100 through a computer network. The configuration 102 
can be stored locally or remotely. The data collection tools 108 may also be running on a 
local or remote machine, related to the other elements. When remotely used, this 
invention is not "intrusive" and cannot directly impact reliability of the target system 104. 

20 

While the foregoing description and drawings represent illustrative embodiments 
of the present invention, it will be understood that various changes and modifications 
may be made without departing from the spirit and scope of the present invention. 
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